feat: support Invidious image proxy endpoints#257
feat: support Invidious image proxy endpoints#257hikiko4ern wants to merge 2 commits intoTeamPiped:mainfrom
Conversation
| } | ||
|
|
||
| #[cfg(feature = "invidious")] | ||
| if matches!(req.path().get(0..4), Some("/vi/") | Some("/sb/")) { |
There was a problem hiding this comment.
Should Invidious endpoints be backwards compatible with Piped? For example, both Invidious and Piped can download video previews via /vi/, but Piped requests them with query (/vi/MYSQe4uuSOA/hq720.jpg?host=i.ytimg.com&qhash=...&rs=...&sqp=...) while Invidious requests them without query (/vi/MYSQe4uuSOA/mqdefault.jpg).
With the current approach they are not backwards compatible, so if a Piped client sends a request to a proxy with invidious feature enabled, qhash and other parameters will not be used and validated. This allows avoiding unnecessary checks for instances running only Piped or only Invidious, but will cause problems for instances running both.
If they need to be backwards compatible, a check that the query is empty could be added here, for example.
| }; | ||
|
|
||
| #[cfg(feature = "avif")] | ||
| if content_type == "image/webp" || content_type == "image/jpeg" && avif { |
There was a problem hiding this comment.
Isn't this check supposed to be like that?
| if content_type == "image/webp" || content_type == "image/jpeg" && avif { | |
| if (content_type == "image/webp" || content_type == "image/jpeg") && avif { |
Now image/webp is always transcoded regardless of the presence of avif in the query, because this check is computed as
if content_type == "image/webp" || (content_type == "image/jpeg" && avif) {
| image_response: Response, | ||
| http_response: &mut HttpResponseBuilder, | ||
| #[cfg(feature = "avif")] avif: bool, | ||
| ) -> Result<Either<HttpResponse, Response>, Box<dyn std::error::Error>> { |
There was a problem hiding this comment.
What behavior is expected in case of transcoding errors? Should the server return 500 Internal Server Error (as it is now) or the original image?
1 participant
So, this is an attempt to add support for Invidious-specific image endpoints.
I marked PR as a draft because I have some questions about expected behavior.
closes #111